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1.0 INTRODUCTION 

The Architecture for Survivable Systems Processing (ASSP) program is a two 
phase program whose objective is the derivation, specification, development and 
validation of an open system architecture capable of supporting advanced processing 
needs of space, ground, and launch vehicle applications. 

The output of the first phase is a set of hardware and software standards and 
specifications defining this architecture at three distinct levels. The lowest level 
consists of the hardware bus(es), operating system, and software development 
environment. It facilitates the interoperability/interchangeability of heterogeneous 
processors for the processing subsystem. The middle level is the intraplatform 
networking of the subsystems such as the data processing subsystem with the 
communication and other subsystems, as shown in Figure 1-1. The sensor and signal 
processing subsystems, although frequently connected by point-to-point links, may 
also be candidates for networking technology. The top level is the interplatform 
networking between common platforms, and to platforms of other system elements. In 
most cases, existing standards will be adequate; specification of these standards is all 
that will be required. Where standards do not exist or are inadequate, specifications 
will be developed. These specifications will be approved by the government 
Technical Advisory Group (TAG) to insure non-parochial interests and eventual 
acceptance by appropriate standards committees. The first phase output will include 
breadboard implementations of ASSP specified interconnection technology. This 
breadboard will be implemented in flight deployable hardware, to demonstrate the 
architectures capabilities as defined in the SOW. 
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FIGURE 1-1: Application of Networks within a Surveillance Satellite 

The second phase of the ASSP program will validate these standards and 
develop any technology necessary to achieve strategic hardness, packaging density, 
throughput requirements, and inter-operability/inter-changeability. 
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2.0 PROBLEM STATEMENT 

The Follow - on Early Warning System (FEWS) and Brilliant Eyes (BE) are 
some of several specific programs whose requirements are being used to drive the 
ASSP program. They were selected because of stressing operational requirements, 
that will need: 

1. Interplatform communication standards between satellites from 
different contractors and ground stations. 

2. Backplane and intrasatellite network standards to minimize 
breakage during Block to Block transitions as the processing loads 
shifts from ground to space. 

3. Interplatform communication standards between Satellite 
constellations ( BE, FEWS, DSP-upgrades etc. terminal defense systems 
(GSTS, THAAD, E 2 I, etc.), and the ground stations during EOAC and 
GPALS. Figure 2-1 summarizes the benefits of ASSP in this context. 

The selection of standard intrasatellite network architectures can minimize the 
re-design of the interfaces between subsystems during block upgrades, Similarly the 
selection of a standard backplane can simplify upgrading from Block to Block. For 
example, a 16-bit processor can be replaced with a 32-bit processor that both interface 
to the same backplane, yielding an order of magnitude improvement in throughput 
with minimal impact on other board designs. Finally, the selection of a standard 
operating system interface will allow applications software developed to be reused 
ensuring cost effective transitions. 

The selection of interplatform communication standards mitigates the risk that 
Satellite constellations can interchange handoff messages with interceptor systems, 
and deliver summary messages direct-to-users. 


3.0 ASSP NETWORKING SOLUTIONS 

The International Standards Organization (ISO) developed the Open Systems 
Interconnect (OSI) standard in response to the growing need in the commercial 
community for interoperability among different computer vendors. That same need is 
now manifesting itself in the defense community. ASSP was conceived with the idea 
of taking advantage of the significant commercial investment in OSI technology, while 
also bridging the differences in networking requirements between the commercial and 
defense communities. BE and FEWS are examples of programs that have portability, 
upgradeability, and interoperability requirements that can be met through the work 
being performed on the ASSP program. This section will provide a brief overview of 
the state-of-the-art commercial OSI technology and how ASSP is utilizing that to solve 
problems for programs like Integrated Satellite Control Systems (ISCS), Common 
Communications Components (COM 3 ), and Corporate Information Management (CIM) 
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Figure 3-1 shows the layers that make up the OSI Reference Model. This model 
is based upon the well-known principle of "information hiding". To reduce design 
complexity and promote portability and interoperability the OSI Reference Model uses 
layers, where each layer builds upon the services/functions offered by its predecessor. 
The purpose of each layer is to offer specific services to the higher layers, shielding 
those layers from the implementation details of how the service is implemented. Thus, 
by standardizing only the interface between layers, and not the implementation, 
implementations can change without having to modify higher layers. For example, the 
Network Layer is primarily concerned with routing messages between processors. If 
the routing scheme were to change, the Transport Layer and all higher layers are 
shielded from this change - requiring little or no modification to their implementation. 
This is a powerful concept that allows much easier insertion of new communication 
technologies with minimal cost and schedule impact. 

The challenge facing the military community is how to take advantage of this 
networking standard and the significant commercial investment in associated 
technologies. Most of the commercial use of the OSI standard is in Local Area 
Networks (LANs) on the manufacturing floor or in the office. Although the defense 
community can make use of this work (and is), the real need is for the use of standards 
in embedded systems. The embedded environment offers much more stringent 
communication requirements than the corresponding manufacturing or office 
environments. In addition, high throughput density and reliability requirements, and 
the emergence of advanced backplanes, combine to cause networking concepts to be 
applied at the backplane as well as the traditional LAN level. Very high speed, 
efficient communications are required in an environment that places severe 
restrictions on size, weight, and power. Thus, communication protocols must be 
specified/developed that are not computer and/or memory intensive. ASSP's mission 
is to provide a suite of protocols that satisfy the OSI standard and meet the 
requirements of the embedded environment. 


Layer No. Name 

Protocol 

7 

Application 

Supplies user services, application-specific standards 

6 

Presentation 

Provides code conversion, data reformatting 

5 

Session 

Coordinates interactions between end application processes 

4 

Transport 

Ensures end-to-end data integrity and quality of service 

3 

Network 

Switches and routes information 

2 

Data Link 

Transfers information to other end of physical channel; controls media 
access 

1 

Physical 

Transmits bit stream over the medium 


FIGURE 3-1: ISO/OSI Reference Model 
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3.1 Application Through Network Layers 


The Application Layer through the Network Layer provide communication 
services accessible by application programs. These layers provide services such as 
guaranteed message delivery, checkpoint/rollback, security, encryption, data 
conversion, etc. The lower two layers (Data Link and Physical) are primarily 
concerned with managing the physical communication medium (twisted pair copper 
wire, coaxial cable, fiber optics, parallel backplanes, RF links, etc.) and are discussed 
separately in Section 3.2. 

For each of the layers, the OSI Reference Model specifies numerous options. It 
recognizes that there is not one all encompassing set of network functionality that 
satisfies the communication needs of every user. Thus, for each of the OSI layers, 
there exist many protocols that provide all or part of the functionality specified by the 
OSI Reference Model. In addition, there exist standard "profiles" which specify a suite 
of protocols that provide a single OSI implementation. For example, the MAP and TOP 
profiles specify a standard OSI implementation (including specific options that are 
mandatory) for manufacturing and office environments. Each specifies protocols that 
provide functionality that best satisfies the needs of each environment. ASSP will 
develop a similar embedded systems OSI profile, where specific functionality is 
required for each layer in order to interoperate with other systems implementing the 
same profile. Existing commercial protocols will be used extensively in the creation of 
this embedded systems OSI profile. Figure 3.1-1 shows some of the sources we will 
draw upon as well as a tentative list of specific protocols that will make up the 
embedded systems OSI profile. 
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FIGURE 3.1-1: ASSP OSI Architecture 
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ASSP recognizes that not all applications need to start at the top of the OSI 
"stack" in order to send/receive messages. Therefore, options of implementing "short 
stacks" and/or "layer bypassing" will be provided. A "short stack" is one in which only 
the layers necessary to meet a specific application's communication requirements are 
present. Thus, the overhead associated with sending/receiving a message can be 
significantly reduced. The cost for this, of course, is in decreased reliability, 
functionality, and/or security for the transmitted/received message. However, in 
embedded systems, this is often an acceptable trade in order to increase 
communications throughput. "Layer bypassing" can be used to decrease the 
overhead associated with the transmission/reception of an individual message. With a 
full ASSP OSI stack present, an application can choose to send a message using the 
functions associated with specific layer(s). This is useful when only selected 
messages require faster transmission/reception, while others require the full 
functionality offered by the ASSP embedded systems profile. 

Use of the embedded systems profile developed by ASSP will allow Platforms 
to meet portability, upgradeability, and interoperability requirements. Its use will allow 
satellites developed by different contractors to communicate with each other and 
common ground stations. The upper layers will provide standard functionality that will 
support this interoperation. Factors such as buffer overflow, message 
acknowledgement, lost packets, data conversion, etc., that previously fell into the O/S 
or applications' domain, are handled by the upper layers of the embedded systems 
profile. Many of the details of the communication links are hidden from application 
developers, thus each contractor has less complex (and therefore lower risk) software 
designs. An additional benefit is that specific satellites should be able to easily 
communicate with other systems (such as BE, FEWS, MILSATCOM, GBR, J-STARS) 
that also use the ASSP embedded systems profile. 

In addition, use of the ASSP embedded systems profile will ease the 
portability/upgradeability problems like the BE contractor will face in moving from the 
Block 1 satellites to Block 2. Because applications are hidden from the details of 
communications and networking, new technologies can be easily inserted without 
affecting the applications. Only the implementation of the OSI layer(s) that is affected 
by such a technology insertion would change. Therefore, the risk of upgrading from 
Block 1 to Block 2 is significantly decreased by the use of the embedded systems 
profile developed by ASSP. 

3.2 Link Layer and Physical Layer 

The link and physical layers of data communications within satellite 
architectures could consist of the hardware required to implement interconnection 
within and between spacecraft, as well as of up/down link communications hardware. 
ASSP technology development will result in lower cost, shorter schedules, and 
improved performance. These benefits accrue from early definition, specification, and 
development of the principal hardware interfaces required for candidate designs. Four 
types of interface standards will be developed by ASSP which are projected for 
Spacecraft application: backplane, high-speed serial, R-F link, and sensor/signal 
processor interface. Application of these technologies are as follows: backplanes for 
Payload Data &/ or Mission Data Processors; high-speed serial for Communications 
Subsystem, S/C Control Subnetworks, and S/C Management Subnetworks; radio- 
frequency for Cross-link and Up/Down link networks; and, sensor/signal processor 
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interfaces for interface between Sensors and Signal Processors, or between Signal 
Processors and Data or Mission Processors. 

Interconnection standards specification and technology development 
independent from system contractors is appropriate because an independent effort, 
such as ASSP, can address the needs of all system elements and ensure compatibility 
between BE, FEWS, and other GPALS elements. In addition, the independent 
specifications provided by ASSP will facilitate technology insertion and lower risk for 
individual projects. 

First, ASSP will develop not just technology trades and roadmaps, but detailed 
specifications for a backplane, high-speed serial network, R-F network, and sensor/SP 
l/F’s which are specific to space-based surveillance platforms. These specifications 
will include the following: 

• Physical Interfaces - drivers/receivers, connectors, media 
characteristics, frequency and loading performance, etc. 

• Media Access Protocol - encoding, clocking, arbitration, 
control/modes, handshake, error detection, etc. 

• Logical Link Services - virtual channels, addressing, flow control, 
buffer management, burst and latency performance, multiprocessing and 
DMA support, error recovery, etc. 

These specifications will constrain implementation of the interconnection hardware for 
the four target technology types (backplane, high-speed serial, etc.). The advantages 
of ASSP specifications will be that they will make maximum use of advanced "open", 
nonproprietary standards such as Futurebus+ and FDDI, and will extend them to 
accommodate size, weight , power, environment (including radiation), fault tolerance, 
and other requirements for space applications. This will allow maximum flexibility in 
prototyping and software development while providing highly capable technologies for 
space use. 

Second, ASSP will develop components which fill technology gaps, and 
integrate these with other available components to build and validate integrated 
interconnection hardware for each of the four interconnection types. This includes 
hardware design instantiations of the backplane, high-speed serial network, R-F 
network, and sensor/SP interface specifications. Any new hardware designs will be 
done in VHDL and targetable to radiation-hardened VLSI libraries. Hardware for each 
interconnection type will be integrated and will include low-level communications 
management, buffering, control, protocol, error recovery, encoding, driving/receiving, 
connectors, and media, among other functions. Verification/validation of each 
interconnection network type will include demonstration of specific GPALS, FEWS 
threat detection and tracking applications. This will ensure the ability to handle the 
desired surveillance communication traffic at all interconnection levels. 

Finally, in Phase II ASSP will update protocols and services, provide additional 
packaging density, and integrate strategically hardened prototype interconnections 
networks. These upgraded networks will be compatible with prior designs due to the 
open system development strategy of ASSP. Thus, transition to more stressing 
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onboard processing for FEWS would be smoothly accommodated using ASSP 
technology and specifications. 


4.0 OPERATING SYSTEM SOLUTIONS 

Satellites developed and launched within the Integrated Satellite Control 
System (ISCS) directives will require the latest software technology to produce 
realtime, embedded software systems that will ensure performance, reliability and long 
operational life that will live up to the expectations of the proposed systems. 

The ASSP program is the source for the requirements and specifications for 
such systems. By adopting an "open system" approach and striving to adapt from the 
best commercial, university, and government non-proprietary products, ASSP will 
specify an operating system based upon commercial standards, protocols and rules 
and DoD, NASA are in a position to profit. 

Three major structural characteristics point up the utility of the ASSP Operating 
System (O/S): a standardized application programming interface (POSIX, ISO 9945-1 
and ISO 9945-2), support for Ada applications executing in realtime, and portability of 
the O/S kernel that will ease the risk of hardware upgrade to higher performance 
processors. The following discusses each of these characteristics in detail. 

The IEEE standards group has defined a Portable Operating System Interface, 
extended (POSIX) for the C language, that initially came out in 1988. It has been 
extended to cover realtime, multitasking, and the Ada language. This standard defines 
the function calls to the underlying operating system such that an application will get 
the same service on any host as long as the host O/S meets the same POSIX 
standard. The ASSP program is working with the IEEE standards groups to select the 
proper subset of these specifications that support the BE, FEWS class of problems. By 
writing the software following the POSIX standard, future upgrades will have minimum 
software risk. 

The Department of Defense has defined Ada (DoD-STD-1815A) to be the high 
order software language for realtime, embedded systems. This is a large step along 
the way to having a repository of reusable realtime code. However, an additional step 
is needed: the application program interface to the operating system on the host 
computer must also be defined by an accepted standard. Otherwise, the reusable 
software is the oft-stated 95% complete with the other 5% costing the usual non- 
recurring. 

The ASSP O/S has a layered structure (see Figure 4-1); the kernel layer 
touches and controls the host hardware, the service/policy layer is made up of the 
major functions (written in Ada packages) that are needed by the applications, and the 
applications layer has network and system management software in addition to the 
mission software written by the user. The service layer can be tailored to the needs of 
the applications, ensuring minimum data latency and the realtime performance 
required. The OSI stack for network communications is in the service layer and this 
standard set of protocols provides for interoperability among satellites in or out of their 
constellations. 
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FIGURE 4-1: ASSP Operating System Diagram 

The kernel layer of the ASSP O/S is very "lightweight," allocating all functions not 
absolutely required to control the hardware to the service layer. This contributes 
significantly to the portability of the kernel to other hosts. When higher performance 
hardware is required, the O/S can be ported to the new hardware, the Ada application 
software recompiled, and the upgraded system is ready for integration and test. 

The ASSP program also includes fault tolerance in the O/S from the initial 
specifications to implementation. The system configuration design to meet the 
reliability and long life will be amply supported by the controlling software. 


5.0 SOFTWARE DEVELOPMENT ENVIRONMENT 

ASSP will develop a software development platform (SDP) that will support the 
development of distributed applications targeted for the ASSP environment. State-of- 
the-art Computer-Aided Software Engineering (CASE) tools will be provided to aid the 
developer in working with the ASSP O/S and embedded systems OSI profile. Central 
to the SDP will be the use of a common "software backplane" that provides a 
framework for building and managing an integrated software development 
environment. 

Features include a common data repository, repository services, and a standard 
user interface. Since all data stored in the data repository can be accessed through 
standard interfaces provided by the software backplane, integration of commercially 
available tools and easy replacement/addition of new tools is supported. This is 
particularly important in support of upgradeability and lower life cycle cost for long-life 
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programs. Given a 15-20 year program lifetime, it is vital that the SDP support the 
insertion of new tools/technologies. By conforming to standards in this area, the ASSP 
SDP insures that developers are not "stranded" in the development cycle using 
old/obsolete tools. 


6.0 ASSP SYSTEM SIMULATION SOLUTIONS 

One of the principal ASSP outputs is a global, all inclusive simulation of the 
interaction of surveillance communications subnetworks. This simulation will be used 
to verify protocols, fault tolerance, network capacity, etc. Communications interactions 
are probably the most fundamentally difficult processing problems to analyze without 
simulation. 

Space based as well as ground application programs can benefit greatly from 
the ASSP simulation tool technology development. ASSP will provide model library, 
user interface, and inter-simulation data transfer enhancements to the most popular 
commercially supported communications simulations packages. The enhancements 
will be fully documented and supported so that contractors will have a user friendly, 
highly capable simulation available which already has detailed library models of all 
the relevant system interconnection components and protocols. Availability of the 
ASSP documented and verified simulation tool allows communications simulations 
performed by multiple contractors and/or by multiple system elements to be combined 
to form large multi-system simulations. 


7.0 CONCLUSION 

The ASSP program directly responds to common government/industry 
deficiencies in providing architecture profiles that can support and upgrade processing 
systems without major redesigns, and procurements. It responds as well to the 
directives and goals for Corporate Information Management (CIM), Modular Open 
System Architecture Standards (MOSAS) and the Common Communication 
Components (Com 3 ). This program provides capabilities to launch processing 
networks that are versatile, offer various levels of complexity and are capable of rapid 
upgrades in mission profiles, hardware, and operating systems. The capability to 
incorporate commercial hardware breakthroughs along with their respective software 
support in a very short time frame and with a minimum of redesign//retooling provides 
significant Life Cycle Cost (LCC) savings and is most beneficial and advantageous to 
the DoD. 

Feasibility demonstrations with preliminary System/Segment Design 
Documentation deliverables are scheduled at the completion of Phase la (FY92). 
Phase 1 b and Phase 2 can be regarded as options to be exercised as directed by the 
ASSP Program Office. 
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